Expand description
Higher level wallet functions which can be used by callers to operate on the wallet, as well as helpers to invoke and instantiate wallets and listeners
Re-exports§
pub use crate::slate::ParticipantData;
pub use crate::slate::ParticipantMessageData;
pub use crate::slate::Slate;
pub use crate::slate_versions::SlateVersion;
pub use crate::slate_versions::VersionedCoinbase;
pub use crate::slate_versions::VersionedSlate;
pub use crate::slate_versions::CURRENT_SLATE_VERSION;
pub use crate::slate_versions::EPIC_BLOCK_HEADER_VERSION;
pub use api_impl::owner_updater::StatusMessage;
pub use api_impl::types::InitTxArgs;
pub use api_impl::types::InitTxSendArgs;
pub use api_impl::types::IssueInvoiceTxArgs;
pub use api_impl::types::NodeHeightResult;
pub use api_impl::types::OutputCommitMapping;
pub use api_impl::types::PaymentProof;
pub use api_impl::types::SendTXArgs;
pub use api_impl::types::VersionInfo;
pub use slate_versions::ser as dalek_ser;
Modules§
- Functions defining wallet ‘addresses’, i.e. ed2559 keys based on a derivation path
- lower-level wallet functions which build upon core::libtx to perform wallet operations
- Functions for building partial transactions to be passed around during an interactive wallet exchange
- This module contains old slate versions and conversions to the newest slate version Used for serialization and deserialization of slates in a backwards compatible way. Versions earlier than V2 are removed for the 2.0.0 release, but versioning code remains for future needs
Macros§
- Helper for taking a lock on the wallet instance
Structs§
- Map of named accounts to BIP32 paths
- Fees in block to use for coinbase amount calculation
- Block Identifier
- Wrapper for reward output and kernel used when building a coinbase for a mining node. Note: Not serializable, must be converted to necesssary “versioned” representation before serializing to json to ensure compatibility with mining node.
- Holds the context for a single aggsig transaction
- Node version info
- Information about an output that’s being tracked by the wallet. Must be enough to reconstruct the commitment associated with the ouput when the root private key is known.
- Store details of the last scanned block
- Payment proof information. Differs from what is sent via the slate
- Optional transaction information, recorded when an event happens to add or remove funds from a wallet. One Transaction log entry maps to one or many outputs
- Dummy wrapper for the hex-encoded serialized transaction.
- a contained wallet info struct, so automated tests can parse wallet info can add more fields here over time as needed
Enums§
- Error definition Wallet errors, mostly wrappers around underlying crypto or I/O errors.
- Status of an output that’s being tracked by the wallet. Can either be unconfirmed, spent, unspent, or locked (when it’s been used to generate a transaction but we don’t have confirmation that the transaction was broadcasted or mined).
- Types of transactions that can be contained within a TXLog entry
- Enum to determine what amount of scanning is required for a new wallet
Constants§
Traits§
- Encapsulate all wallet-node communication functions. No functions within libwallet should care about communication details
- TODO: Wallets should implement this backend for their storage. All functions here expect that the wallet instance has instantiated itself or stored whatever credentials it needs
- Combined trait to allow dynamic wallet dispatch
- Trait for a provider of wallet lifecycle methods
- Batch trait to update the output data backend atomically. Trying to use a batch after commit MAY result in a panic. Due to this being a trait, the commit method can’t take ownership. TODO: Should these be split into separate batch objects, for outputs, tx_log entries and meta/details?
Functions§
- Check / repair wallet contents by scanning against chain assume wallet contents have been freshly updated with contents of latest block